This article will assist with troubleshooting issues with learners being marked as phished without having interacted with a PhishSim email. First, an explanation of how Infosec IQ will identify what we’re looking for. When a PhishSim campaign is sent, Infosec IQ generates a unique link (URL) for each learner in the campaign. That specific link is associated with that learner and that learner only. If anything or anyone interacts with a link, Infosec IQ will register that as a phished event for the associated learner.
Examine the Phished Event
The first step is to identify the source of the activity. In the IQ admin portal, navigate to Learners > Learner list, find the affected learner, and click Learner Profile. There will be a chronological list of all events related to the learner’s AwareEd and PhishSim campaign activity (see Learner Profile for more information).
Scroll through the list until you find the “Phished” event in question. The event record will list the date and time of the phished event, the campaign name, email template name, and the IP address that interacted with the link. Once you’ve found this, scroll down a bit further till you find the “Sent a Phishing Message” event for this learner and make note of the time. Using this information, we can make a pretty good guess at what happened.
Who or What Clicked the Link?
Search for the IP address from the phished event using any IP address lookup service, e.g. whatismyipaddress.com. This will tell you the registered owner of the IP address, and may provide an approximate location for where the click originated. Here are a few a common results and what they may mean:
- A consumer ISP, commercial ISP, or mobile service provider such as Spectrum, Comcast, or Verizon. If the IP belongs to an internet provider, then the activity is most likely from human interaction on a computer or mobile device. In some cases, the owner of the IP address may even be your organization or a regional ISP in your area.
- Amazon or Amazon Web Services (AWS). If the IP address belongs to Amazon or AWS, the click may have originated from a lot of different places. There are a few things we can rule out though: this probably is not a learner click (AWS is not an internet service provider), and did not originate from any Microsoft or Google services. In most cases, this will narrow the culprit down to a third party mail filter or security service, many of which are hosted on AWS.
- Microsoft or Google. Microsoft and Google host all of their own services and in most cases don’t provide hosting services to other companies. If the IP address is owned by either Microsoft or Google, this probably means the click originated from one their data centers and almost certainly from one of their services. Note: You will most likely only see Microsoft clicks if you’re using Microsoft as your mail hosting service and Google clicks if you’re using Google as your mail hosting service
- Something else. If you don’t recognize the owner of the IP address, it could be a smaller private data hosting service, or it could be a larger regional network such as APNIC or RIPE. There may be some indication of the owner, but if not, you can always use a search engine to see what type of services they provide. Some of these services have their own “WHOIS” where you can look up specific IP addresses to see who owns them.
What is the Timeframe?
Once you’ve identified who or what clicked the link, the next step is to identify when it occurred relative to being sent. This will give us a little more information about what interactions are at play. Compare the timestamp on the “Sent a Phishing Message” event with the timestamp on the “Phished” event, and take note of how long it took the phished event to take place after the message was sent.
- 0 to 30 seconds. If the “phished” happened almost immediately after the message was sent, this will usually point to the phished event happening during the delivery process by a scanner or security service. If the activity is closer to 30 seconds after delivery, there’s a chance that it’s human interaction.
- 30 to 120 seconds. This range can be a little murky. If the phished event took slightly longer than 30 seconds, it can still be a delayed scan and may still point to something during the delivery process, but it’s a little less likely. At this range it can also be a post delivery scanning service (such as endpoint protection) or human interaction happening after delivery.
- More than 120 seconds. Anything greater than two minutes will usually involve some type of user interaction.
Combining the Who and When
Finally, we’ll consider the IPs clicking the links and the time it takes to click.
- Microsoft or Google, 0 to 120 seconds. If the click is happening relatively quickly, and it’s happening from your mail hosting service, there may have been steps missed during allowlisting. See the appropriate article here, or contact Infosec support for assistance.
- Microsoft or Google, >120 seconds. If the click is happening well after the email has been delivered, but it’s still being clicked by your mail hosting service, the learner may be using the default report button for your mail hosting service. Microsoft allows their button to be configured to ignore emails from specific senders (see Additional M365/Exchange Allowlist Rules). Google does not allow their report function to be configured in this way.
- Amazon or other data center, 0 to 90 seconds. If the click is happening relatively quickly, and it’s from an Amazon or AWS IP address, this likely means that there’s a third party mail filter scanning the email during the delivery process. Because it’s Amazon it could be just about anything, but assuming you only have one third party scanning service this should narrow it down. Check your allowlisting here, or contact Infosec support for assistance.
- Amazon or other data center, 60 to 120 seconds. If the click is happening a little slower than you’d expect for message delivery, this could point to a post delivery scanning process. This is rare and can be tricky to troubleshoot, but some services will use the API of your mail hosting service to scan emails after delivery. Check your allowlisting here, or contact Infosec support for assistance.
- Amazon or other data center, >120 seconds. If the click is happening well after delivery, and is being clicked by a data hosting service, this may point to a third-party mail security service’s report button. Most email reporting features can’t be configured to skip specific emails. Check with your mail security service provider to see if anything can be done.
- ISP or mobile provider, >60 seconds. If an ISP or mobile service provider is generating a click, the timing doesn’t matter so much, because whatever it is will be relatively erratic. First, this can point to an endpoint security service. It’s rare, but there are some services that will scan emails locally. Second, if it’s a mobile service, check if the user used a link preview feature on their phone, such as the long hold on the iPhone. This will still load the contents of the webpage and generate a click. Finally, this is also what a genuine click will look like. If this is the only claim of a false positive you’ve had, it might be worth probing for more information about what happened, particularly if its happening well after delivery.